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1.0 ABSTRACT 

Fortuitously, the Corporation has decided to finance 
development of a high-availability, high-data-integrity 
multiprocessor system (Hydra) based on the Comet in the same 
time- frame as Dolphin. 

This development will produce all-new 
communications/unit record hardware which has parity on all 
buses, redundant paths to individual line cards, cabling 
which terminates outside the cabinet (for good EMI/RFI 
performance), and power-on replacement of line cards. 

The Hydra hardware makes use of the latest Corporate 
LSI processor for low cost/MIP and the latest communications 
LSI chips. 

Hydra can contribute to Dolphin the most cost-effective 
hardware available for the Dolphin generation as well as a 
low-overhead high-speed CPU interconnect bus. Hydra also 
contributes data integrity and hi-availability to Dolphin 
when it appeared that Comm/Unit Record would be our 
"Achilles Heel" 

Because the Hydra hardware is all-new, and because 
Tewksbury is such a focus of new-product activity it appears 
disorganized, there seems to be a high risk in casting our 
lot with Hydra/Mercury for Dolphin I/O. 

On the other hand, if Hydra fails, not only does the 
Corporation suffer a severe NOR blow, but Dolphin will have 
to compromise its RAMP goals which constitute such a large 
part of the machine's design effort. 

We have a plan to use the Hydra/Mercury hardware on 
D/36 and D/32. All we have to do is manage it so that it 
happens. 
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2.0 DOLPHIN PRODUCT MANAGEMENT REQUIREMENTS FOR COMM/UNIT RECORD 

Following is a summary of Product Management 
requirements for Dolphin Comm/Unit Record obtained from John 
Jorgensen's memo (11/17/78 "Optimum Configurations") and 
from a subsequent verbally expressed request from John for a 
high-speed local interprocessor link. Line printer 
requirements are not firm yet regarding number and speed of 
units to be supported. Joe Viula will have a plan by 
February 15. A card reader was not specifically requested, 
but it was agreed in the Dolphin Steering Committee that 
provision must exist for a card reader on Dolphin. 

As currently conceived, the HYDRA Comm/UR box (Mercury) 
in combination with the ICCS system appears capable of 
satisfying these requirements. Especially attractive is the 
potential ability to satisfy the availability requirement 
shown for the Large system (99.9%) 

Technical EDP 

Entry Level System 

o Async Lines 16 (4800 BPS) 8 (4800 BPS) 

o Sync Lines 

(local 100K-1MBPS) 2 — - 

o Sync Lines — 6 (19. 2K BPS) 

(multidrop/network) 50 Terminals 

o Availability 98.5% 98.5% 



Technical EDP 

Typical System 

o Async Lines 32 (4800 BPS) 64 (4800 BPS) 

o Sync Lines 6 — - 

(local 100K-1MBPS) 

o Sync Lines 2 (56 KB) 8 (56 KB) 

(network/multidrop) 

o Availability 99.1% 99.2% 

Hi-Availability/Capacity 

o Async Lines 128 128-200 

o Sync Lines 6 2 
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(local 100K-1MBPS) 

o Sync Lines 

(network/multidrop) 

o Interprocessor Link 
(8M byte/sec) 

o Availability 



4 (56 KB) 
8-64 
99.9% 



(remote or local) 
16 (56 KB) 

8-64 

99.9% 
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3.0 IMPLEMENTATION PLAN 

3.1 Architecture 

Dolphin Comm/Unit Record I/O relies on hardware to be 

produced by the MPS/Hydra group for high-availability 

requirements and an IGCS port adapter produced by LCG for 
the Dolphin bus. 

Fig. 1 shows the basic interconnection scheme for 
Dolphin Comm/Unit Record. This system is the uniprocessor 
version with no hi- availability features. The basic 
architecture consists of a Dolphin/ICCS port, links, 
Fll-based controller, and Line Unit modules for async, sync, 
multidrop, line printer, card reader, and hi-speed long-line 
connections (used for graphic CRT and medium- speed/distance 
CPU-CPU connections) . 

Fig. 2 shows the optional high-availability 
configuration using two Dolphin processors. Note that host 
processors, links, ICCS buses, and controllers are all 
duplicated for redundancy so that the only single point 
failure in the system is an individual line module. 



3.2 ICCS Port, Bus, Link - 

The ICCS bus is a single-wire 5-10 M byte/sec 
packet-oriented contention bus designed for linking 
processors, mass memory, and I/O over a distance of up to 
200 ft. It is being designed in Tewksbury for the 
Comet-based Hydra high-availability system. 

An ICCS bus can accomodate up to 16 "drops" which 
access the wire by means of the Link, which is essentially a 
very-high-speed ECL modulator/demodulator/f ramer . 

A Link is controlled by a Port, which is a buffer/bus 
controller interfaced to the host processor 
hardware/operating system. Devices on the operating system 
have logic in their controllers which perform a port-like 
function. In the case of the Mercury Comm/Unit Record box, 
a "miniport" is planned which mediates between the Link and 
the four Fll controllers. 

LSG Peripheral Engineering has budgeted a project to 
design and release an ICCS Port for Dolphin to support both 
the Mercury Comm/Unit Record box and the HSC50 disk. 

The Mercury communication subsystem consists of two 
parts: an I/O Subsystem and a Line Card Assembly. 
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The I/O Subsystem consists of 6 or 10 modules mounted 
vertically in the Dolphin I/O single highboy cabinet. See 
Fig. 5. The 10 modules break down as follows: 

1 Link Module 

1 Miniport 

4 Communications Microcontroller Modules 

4 Memory Modules (if necessary) 

All of the modules in the I/O Subsystem are extended 
hex modules. 



3.2.1 Physical Package - 

A study was done by John Bisol and Tom Dundon to determine: 

o Is a double-width Comm/I/0 cabinet more 
efficient in terms of density than a 
single-width cabinet? 

o Does provision for hi-availability 
controllers impose a significant cost 
burden on non-high availability users? 

The answers are: 

o A single-width cabinet is slightly more 
dense, so there is no reason to impose 
the extra size/cost of a double-width 
cabinet on all users. 

o The major potential cost deltas for 
hi-availability are: card cage, 
backpanel, and power. Power supply 
modularity is such that a regulator 
module (+5V) need simply be added for 
the hi-availability configuration and 
deleted for the standard one. Card cage 
cost delta for 12 slots vs 6 slots is 
$30-$40. Backpanel cost for 6 slots is 
about $110, and could be added at 
hi-availability conversion time. Thus, 
cost penalty for providing for 
hi-availability is either $40 or $150, 
which seems reasonable. 

Figure 4 shows a proposed Comm/UR cabinet layout using two rows 

of line units. If 12 extended-hex cards are provided for, 60 line 

unit slots are available which could be assigned (for example) as 
follows : 

o 48 async/sync lines to 19.2 KB. 
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o 4 hi-speed sync lines to 56KB 

o 1 Line printer line unit 

o 1 Card reader line unit (or 2 line 
printers and card readers) 

An alternative scheme is being investigated which uses 3 rows of 
line units in a slightly higher card cage. If we allow 1 spare 
ext-hex slot per controller group (14 slots total) , we have 
28 X 3 - 84 line slots available which could be configured (for 
example) like: 

o 64 async/sync lines to 19.2 KB 

o 4 hi-speed sync lines to 56 KB 

o 1 Line printer line unit 

o 1 Card reader line unit (or 2 
line printers) 

Note: One multidrop "DMC" line unit may be substituted for 
the hi-speed sync lines in graphics applications. 



3.3 Line Card Assembly 

The Line Card Assembly consists of 64 modules mounted 
in the lower rear portion of the Hydra cabinet. The 64 
modules are wired in "line groups" of 16 modules per line 
group, each with access to two microcontrollers. The 
modules are oriented such that the board surfaces are 
horizontal, with the handles toward the rear of the cabinet 
and the finger ends of the module towards the front of the 
cabinet. 
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The Line Card modules are double height modules, 
extended hex depth (5.188" by 11.57"), with special metal 
handles that include the connectors for the communications 
line. Fig. 6 is a sketch of a typical line card handle 

with the designation 



with the integral 


connector marked 


"CONN". 
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The line cards are symetrical in that alternate line 
cards are plugged in "right side up" and the others are 
plugged in "upside down" . This permits use of a wider 
connector than than standard .500" spacing would normally 
permit, and causes the cables to leave the line card 
mounting area in two different directions, easing cable 
congestion. The use of a press-pin backplane permits the 
line cards to be mounted on .400" and .600" center, yielding 
an average of .500", but with the aforementioned wider 
connectors. It is desired to maintain the average of .500" 
spacing rather than going to .600" in order to fit the 
required number of boards in the available space. 

The pinning of the line cards is symetrical to permit a 
single line card design to be used in either the "upside 
down" or the "right side up" placement. The duplicated 
pinning also meets the connection requirements of the two 
"Dash Busses" serving each line card. 

Line card handles will be of widths proportional to 
their bandwidth requirements (see Fig. 3). 

Three line card types will be offered at First Customer 
Ship. These are: 

1. RS-232-C Synchronous and Asynchronous 

2. CCITT V. 35 Synchronous 

3. RS-232-C Asynchronous (depopulated version of 1 
above) 
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Two additional line cards will be offered 
approximately six months later: 



4. DMCll-style 56 Kbaud/lmegabaud modem 

5. RS-422/423. 



The signal leads supported by line cards 1, 2, and 3 
are : 



Signal 

Protective Ground 

Transmit Data 

Receive Data 

Request to Send 

Ready for Sending 

Data Set Ready 

Signal Ground 

Data Channel Received Line Signal 

Detector 

Transmitter Signal Element Timing 

Receiver Signal Element Timing 

Data Terminal Ready 

Signal Quality Detect/Stand-By 

indicator 

Galling Indicator 

Data Signal Rate Selector 

Select Standby 

Make Busy/Analog Loopback 

Stand By Indicator (U.K.) 

*This circuit requires both a driver and a receiver. 



3.4 Microcontroller 

Each microcontroller will consist of a Scanner/Framer 
state machine and a FONZ-11 processor with 32K bytes of MOS 
memory. Each microcontroller will be connected to a line 
frequency clock. The addressing capability of the micro- 
controller will permit memory expansion up to 256K bytes for 
non-HYDRA applications such as DECsystem 20 front ends, 
DECnet nodes, etc. An attempt will be made to provide all 
256K bytes on a single controller module. The Scanner/ 
Framer will provide substantial assistance to the FONZ by 
calculating CRCs for non-SDLC protocols ( in SDLC the LSI 
USART chip will do the CRC) , detecting special characters, 
depositing messages directly into FONZ memory, etc. (see 
Fig. 10) . 
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The FONZ will manage message tables and assemble 
messages for transmission to the Miniport and Link, thence 
to the ICCS. 



3.5 Design Goals 

1. Reliability 

The Mercury communications subsystem will be 
designed in a conservative fashion, using logic 
families well proven in previous Digital designs 
principally low power Schottky. All busses 
connecting modules in the Mercury system will have 
both data and address leads protected by an error 
detection system. 

2. Availability 

For each communications line in a Mercury 
system, there will be a readily replaceable line 
card. On the optional hi- availability 
configuration, each line card will have access to 
two communications microcontrollers, each of which 
has its own access paths to both Comet processors. 

3. Maintainability 

As indicated in Figure 2, it is possible for 
either Dolphin processor to communicate with a line 
card by either of two Link - Miniport 
Microcontroller paths. Thus, it will be possible 
for maintenance personnel t6 power down and replace 
any Link, Miniport, or Microcontroller module 
without interfering with users. 

Line cards can be replaced with the power on, 
even on Uniprocessor systems, thus limiting the 
effects of a line card failure to a single line. 

4 . Performance 

The Mercury communications subsystem will 
contain microcontrollers which can echo received 
characters from asynchronous terminals, supervise 
the transmission and re-transmission of messages 
containing error detection protocol features, and 
prepare message packets for transmission over the 
ICCS high speed packet bus to the Dolphin 
processors. 
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3.6 Backup Plan 



The original Dolphin Comm/UR plan (see Drumm 5/78) is 
available as a backup to the Hydra/Mercury/ICCS plan 
described herein. 

The backup configuration will actually be tested on 
early Dolphin breadboards, using KS10 software with a 
modified Unibus Adapter driver. 

Backup configuration consists of KMC, DUP, DZll, LP20, 
and CD20 devices on the Unibus of the Dolphin UBA (see the 
original Dolphin Plan, July 1978. 

While the backup plan will allow shipment of Dolphin, 
it requires compromising goals of: 

1. Performance (no "front-end" controllers) 

2. Data Integrity (no parity on Unibus) 

3. Availability (many single-point failures, no live 
line-card replacement) . 

4. Functionality (no hi-speed inter - CPU link if ICCS 
not done) . 



We must make a decision on ICCS/Mercury vs. the backup 
by June 1979. 
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4.0 SCHEDULE AND STAFFING 



The Dolphin Comm/Unit Record project is scheduled as 
shown in Fig. 7. A corresponding software schedule will 
appear m the Dolphin Software Plan, due in February 1979. 

A schedule for the ICCS port exists, but is not 
included in this plan. 

Staffing presently included in the LSG budget for 
Communications/U.R on Dolphin is shown below: 



4.1 Hardware - Manager: Phil Wilson 



- Supervisor: Paul Kelley 



STAFFING (MAN-QUARTERS) 
FY79 FY80 FY81 



Engineer 

Tech 

Diagnostic Engineer 

Supervisor 



0.5 



3 
2 

4 
1 



3 
4 
1 

1 



4.2 Software - Program Manager: Peter Hurley 



- Comnets Manager: Steve Meidell 
STAFFING (MAN-QUARTERS) 
FY79 FY80 FY81 FY82 



Monitor Group 
Comnets 



6.2 
2 



22.2 
11.5 



34 
27 



16 
8 
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4.3 Milestone Summary: 

1. Mercury Spec 3/79 

2. Hardware Design Done 7/79 

3. Dolphin Mercury Proto Available 

4. ICCS Port Running (BBD) 

5. Proto Mercury/ICCS Running 

6. Mercury Mechanical Release 

7. FCS 



4/80 

7/2/80 

12/12/80 

9/1/80 

6/1/81 
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5.0 PERFORMANCE 



Several factors make it difficult to present a clear picture 
of communications performance on Dolphin. Among them are: 

— non-existence of a spec for the software 
running in the controllers. 

— unknown impact of future Decnet evolution 
on performance (esp. routing) . 

— lack of data on synchronous performance 
of KL/KS generation of PDPl0's due to 
personnel priorities. 

However, some information is known about current 
communications overhead and performance. Goals have been 
set for Dolphin and Hydra. 

I have decided to describe what we know and where we 
are in the three areas which together result in a given 
level of system performance. These areas are: 

1. Thruput of Communications/UR hardware. 

2. Thruput of controller software. 

3. Thruput of host system. 



5.1 Thruput Of Comm/U.R. Hardware 

John McNamara in his "Mercury Communications System 
Spec" dated February 6, 1979, has specified performance 
goals of the Mercury subsystem as used on Hydra, with Hydra 
Communications software running in the controllers. It is 
unlikely that we can use all the Hydra software directly 
because we do Decnet and asynchronous service differently 
than VAX. (LSG Comnets software considerations are 
discussed in Sect 5.2). 

However, the following text is intended to describe 
performance goals stated for Hydra, and indicates the 
performance potential of the hardware/firmware. 

The performance figures quoted below are based on the 
assumption that the ability of a line card to access two 
microcontrollers is used strictly for availability purposes, 
not for performance enhancement. 

The Mercury system can operate: 

4 lines at 1 megabaud full duplex (1 line per 
controller) or 32 lines at 56 kilobaud full duplex (8 lines 
per controller) or 64 lines at 19.2 kilobaud full duplex (16 
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riquJstr' ''°"*^'°^^^'^) ^"^ 128 lines at 4800 baud FDX (LSG 
followsr^ ^^"^ speeds and quantities may be traded off as 

one 1 megabaud line = eight 56 kilobaud lines 

one 56 kilobaud line = two 19.2 kilobaud lines 

It is assumed in the above figures that eight bit 
characters are being used, and that the protocol limit 
options m section V. are observed. 

hv hooi^^^^ u°^! ^^^^ ^^^ ^^°^^ performance may be limited 
by host overhead. Based on experience to date on DEC System 
-itJf It will be. (see Sect 5.3) 

Unit record devices will be supported as follows: 

onl IIZ ^^""^ P^"" ""^""^^ ^^^'^ ^^^^^^ = 1 56 kilobaud line 
one 2000 line per minute line printer = 1 56 kilobaud line 

Customer Ship. ''"""'' support will be provided at First 

Line cards designed to support 56 kilobaud lines 
specifically the V. 35 line card identified as itne caJS 2 
in Section IV, and the "line cards" for the card reader and 

sich tha^^hpv J'^r'^'^fK "^°^^ ^^^^ double width handles 
such that they take up the physical space of two normal line 

?hfcl* ^ "^ ''^^' ^^^ ^^^^ connectors associated with 

speSffic^^-nn^ ""f^i ^K accommodated and the performance 

cha'rLte^istics."''' '' '"'"'^^^' by the physical mounting 



5.1.1 Protocol Support - 

To maintain the performance specifications for the Mercury system 

receTi^'°'rr°''^^^ P"°^'^^ ^^^ protocol assistance neceLary to' 
receive and transmit messages. The protocols supported on Hydra 

1. VAX/VMS Asynchronous Terminal, Card Reader, 
and Line Printer Drivers 

2. SDLC 

3. X. 25/HDLC 

4. DDCMP 

5. Bisync 

6. 3271 emulation and hosting 

7. 2780 emulation 

8. The proposed 56 kilobaud terminal bus 
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A line group of sixteen lines may operate any three of these 
protocols simultaneously. 

Multidrop lines are supported on Mercury. A sixteen line group may 
have as many as 256 point to point or multidrop terminals 
associated with it. These terminals may be arranged as 1 on each 
of fifteen point to point lines with 241 on the sixteenth lines, or 
some combination in between. 

All SDLC support will assume eight bit characters. No fractional 
length character support will be provided by the hardware or by 
the software. 

The use of the BISYNC protocol shall be limited to speeds of 19.2 
kilobaud and below. 



5.2 Thruput Of Controller Software 



The Marlboro Monitor and Comnets groups will be rewriting and 
repartitioning TOPS-20 communications software for Dolphin. It 
is not currently known how much of the Hydra controller software 
can be used by Dolphin, but certain differences in requirements 
are known now. They are: 



Asynchronous service will be do 
style, not VAX styre. 
The Bisync protocol is a higher 
for us than for Hydra, and SDLC 
Line Printer/Card Reader servic 
to emulate the LP20/CD20 logica 
to the host. This may differ f 
Hydra implementation. 
We may put much more NSP-level 
controller than Hydra, who evid 
keep such functions as routing 
for high-availability reasons 



ne TOPS-20 

priority 
i s lowe r . 
e will have 
1 interface 
rom the 

code in the 
ently must 
in the host 



Note: This section to be completed after consulting with Steve 
Meidell, Pete Hurley, John Hall ybur ton and Buren Hoffman. 



5.3 Thruput Of Host System 

Mercury thruput goals listed in Sect. 5.1 imply that 
Host performance will determine total communications 
thruput, assuming that Dolphin controller software doesn't 
dramatically alter the controller performance. 
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In this Section, results of KL10 thruput measurements 
are given, and projections of Dolphin performance are made. 
Sample communications configurations are shown based on 
aggregate communications service taking 20% of host computes 
in a balanced system. 



5.3.1 Asynchronous Service: - 

Asynchronous overhead was measured rather thoroughly in 
the KL10 and amounts to 1 ms for an input character and 200 
microseconds for an output character (see Table 1) . 

On Dolphin, initial planning calls for TTYSER to stay 
in the host except for XOFF processing. However, larger 
blocks are expected to be passed between controller and 
host. A TTYSER bypass will allow direct block input from 
terminal to job on asynchronous ports, with the controller 
looking for end-ofrblock sequence. 

The 3:1 overhead reduction is achieved by a faster host 
and the above changes. 



5.3.2 Synchronous Service: - 

Measurements of synchronous overhead are still not 
complete, but existing data is shown in Table 1 and is 
applicable to DECNET only. Overhead for other protocols has 
not been measured. 

On Dolphin, DDCMP-level and much network-level work is 
planned to be done in the controller, as in the DN20. 
Overhead reduction of 4:1 is planned by a faster host and by 
a BLT which packs 8-bit characters into 36 bit words for 
transfer of binary files. 

DECNET is adding functionality (like routing and 
transport layer) rapidly in this time frame. Overhead may 
very well go higher than at present if not watched closely. 



5.3.3 Polled Multidrop Service (T.P.S.) - 

The data shown in Table 1 was derived from a KS10 
measurement and scaled for the KL. It may not be very 
accurate, but indicates that polled multidrop may be a 
low-overhead way to connect terminals. More accurate data 
will be available after TPS is debugged. 
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Improvement for Dolphin is expected due to host speed 
increase and reduced overhead from ICCS port. 



5.3.4 Hi-Speed Graphics Service: - 

While not offered for sale on current 20-based systems, 
Marlboro has an extensive graphics facility on System 1031 
connected through two DL10's. 

Measurements on this system indicate that actual I/O 
overhead is quite low (about 0.5% of KL per terminal), but 
picture-processing takes about 10% of the CPU per terminal, 
using the typical operation of translation of the screen 
"window" thru a picture file at the rate of one move per 4 
seconds. 

Improvement on Dolphin is anticipated because of the 
faster host and because some work (such as CRC) may be 
offloaded to the controller. 



5.3.5 Sample KL And Dolphin Configurations: - 

In the samples below, the configurations are chosed so 
that they take no more than about 20% of a Dolphin, assuming 
that the workload stimulated by this amount of 
communications traffic requires the other 80% for monitor, 
I/O and computes. 



Technical System 



Overhead 



- 80 active async (4800) 

- 4 graphic (500 KBPS) 

- 4 sync (9600 BPS) 

- Polled TPS 



KL 

12% 

40% 

14% 





Dolphin 

4.0% 
13.3% 
3.5% 




EDP System 



66% 



21.7% 



- 120 active async (4800) 

Graphic 

- 12 sync (9600 BPS) 

- 16 TPS lines (9600 BPS) 
(10 terminals/line) 



18% 


44% 

8% 

7f% 



6 .0% 

11.0% 
2.0% 

19.0% 
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6.0 KL VS. DOLPHIN COMM/U.R. COST COMPARISON 



This portion of the Plan attempts to compare KL and Dolphin 
costs for asynchronous lines, synchronous lines, line printer 
interface, and card reader interface. Section 6.1 chooses 
four representative systems and compares cost and 
cost-performance between KL and Dolphin. The following sections 
contain detailed cost estimates which allow cost comparison 
for any given configuration. 

In addition to the data shown, it should be recognized that 
Dolphin/Mercury hardware offers: 

~ More combinational flexibility than KL 
due to the unit nature of line modules. 

— A means of limiting Comm/U.R. failures 
to a single line. 

— Ease of adding OEM controller code for 
special devices in dedicated Fll 
controller. The KL never really solved 
this problem at reasonable cost. 



6.1 SAMPLE SYSTEM COMPARISONS 

The systems shown below were chosen as representatives of low-end, 
design center and high-end systems. They do not correspond 
exactly to the systems in Section 2.0 because some Dolphin 
options were not available on KL. 

- SYSTEM "A" (low-end) 

~ Async = 32 @ 4800 baud 

— Sync = 2 @ 19,200 baud 

— Printer =1 (space reserved for 2) 

— Card Reader =0 (space reserved for 1) 

Cost Performance (1) Cost/Performance 

KL 11,365 1 1 

Dolphin 6,228 3.5 6.4 

- SYSTEM "B" (design center - EDP) 

— Async = 64 § 4800 baud 

— sync = 8 @ 19,200 baud 

— Printer = 1 (space for 2) 

— Card Reader =1 

Cost Performance Cost/Performance 

KL 22,228 1 1 

Dolphin 8,628 3.5 9 



Page 19 



SYSTEM "B" (med. availability option) 
(Redundant controllers, dual-port line 
module connections, second ICCS bus, 
added power) . 

— 4 controllers (2 Async $2,650 

1 U.R. 
1 Sync) 

— 2 links 600 

— 1 miniport 300 
—1+5 @85A 300 

— cable hdw, misc. 250 



$4,100 



The above option modified System "B" to add duplicate data paths 
and achieve isolation of failures to a single line module or 
the host. On System "B" . the "medium-availability" option 
would cost $4300 and might sell for $20,000. 

Cost/performance comparison with the non-high-availability KL 
looks like this (assumes no advantage is taken of the redundant 
controllers to enhance performance) : 

Cost Performance Cost/Performance 

KL 22,228 1 1 

Dolphin 12,728 3.5 6 

— SYSTEM "C" (Dual-Processor-Hi End) 

(Dual processor, Comm lines and U.R. 
divided between machines, hi-availability 
(Fig. 2) Hydra config. in Dolphin, KL 
uses MX20) 

— ' Async 
--- Sync 

— Printer 

— CDR 

— MX20 on KL10 (no memory) 

— Hi-availability option on Dolphin 

Cost Performance Cost/Performance 

KL 68,044 1 1 

Dolphin 41,276 3.5 5.8 

NOTE: The Dolphin dual-processor system above is a true 
full-redundant "nonstop" system. The KL is not, except for the 
CPU's and dual-port disks. 
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To sum, the Hydra/Mercury hardware on Dolphin will offer between 
six and nine times the cost/performance of the KL with much 
better RAMP. However, competitive pressures at Dolphin ship 
time may make this gain unacceptable. Our goal should be double 
the above numbers, and we should try to achieve this by 
concentrating on performance as well as cost. 



6.2 KL10 ASYNCHRONOUS COSTS 



(DTE Cost Not Included for 8 - 128 lines) 
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2251 


9-16 


144 


— - 





57 


2308 


17-24 


151 


— '— , 


1326 


— - — 


3634 


25-3 2 


115 


— -— 





57 


3691 


33-40 


209 


3950+724 


incl 


— _ 


8365 


41-48 


175 








57 


8422 


49-56 


174 




1326 


— ._ 


9748 


57-64 


153 








57 


9805 


65-72 


155 


" — -— 


1326 




11131 


73-80 


140 


■ 





57 


11188 


81-88 


142 





1326 





12514 


89-96 


131 





. 


57 


12571 


97-104 


159 


3950 


incl 


■ — - 


16521 


105-112 


148 








57 


16578 


113-120 


149 


— r-- 


1326 


■ — ._ 


17904 


121-128 


140 


: . — 





57 


17961 


129-136 


200 


5916+724+DN20CA 
+DN25DA+DC20CC 





9247 


27208 


137-144 


191 





354 





27562 


145-152 


184 


-' — 


452 


'. — -- 


28014 


153-160 


177 


• 


354 





28368 


161-168 


172 


— — 


452 





28820 


169-176 


166 


- — • 


354 





29174 


177-184 


163 


KMC+DZ+DIST 


858 


^ — ^^- 


30032 


185-192 


158 


■ . 


354 


. 


30386 



(*1) 



(*1) $5916 can be split between sync & async if at least 
1 sync line is needed. (They share u/34 CPU) . 
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6.3 Dolphin Asynchronous Costs 

Assumptions: 

1. No comm/UR equipment is in double width CPU 
cabinet. First single - width cabinet and power 
control and blower costs are included in basic CPU 
cost (for comparison with KL) . 

2. ICCS part on Dolphin costs $1000 (1/2 of adapter) . 
(*2) 

3. Line unit (low async speed) costs $35 . 

4. Line unit (sync/async to 56KB) costs $60 . 

5. Link costs $300 . 

6. 64K Fll controller costs $600 (async/UR) . 

7. 128K Fll controller costs $850 (H.S./sync). 

8. Line unit box (32 lines) costs $50 . 

9. Backpanel (line unit) costs $160 . 

10. Controller box costs $70 . 

11. Controller backpanel costs $110 (6 slot) . 

12. Unit record line unit costs $45 . 

13. Power supply for 64 LU & 4 ER costs $1000 . 

(*2) Do with & without. 

Asynchronous (to 19^ 200 BPS) ; 

CUM 
COST/ COST 

LINES LINE PWR PKG OPTION CABLES TOTAL 



1-8 (Cost = Port (1000) + 8 X CU = (280) + link (300) 

+ Ctrl (64K) = (600) + LUB = ($50) + L.U. backpanel 
= (160) + Ctrl box = ($70) + Ctrl backpanel = ($80) 
+ power supply = ($1000) = ($3540) 

(1-8) 443/ 1000 360 2180 (2540) 

317.50 3540 

9-16 239/ ^~ 280 — (2820)/ 
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3820 


280 


4100 


280 


4388 


280+600 — 


5318 


280 


5598 


280 


5878 


280 


6158 



176.25 

17-24 171 — 

125-32 137 — 

33-40 133 50 

40-48 117 

49-56 105 

57-64 96 

65-72 (Cost =8 X LU (280), link (300) + Ctrl (64K) 
= (600), LUB or = (50), LU backplane (160), 
Ctrl box ($70) , Ctrl backplane = ($80) , PS 

($1000), cab = ($400) (Total = 2940) 

(65-72) 126 1000 760 

73-80 117 — 

87-88 110 — — 

89-96 104 

97-104 105 — 50 

105-112 100 — 

113-120 95 

121-128 91 — 

129-136 (Cost = LU (280), link (300), Ctrl (600), LU box 
(50), LU back (160), Ctrl box (70), Ctrl back- 
plane (80), PS (1000), cab (400). Total 2940 

(129-136) 108 1000 760 

137-144 104 — — - 

145-152 100 

153-160 97 — 

161-168 98 50 

169-176 95 — 

177-184 92 — 

185-192 90 — - — 



1180 


9093 


280 


9378 


280 


9658 


280 


9938 


280+600 


10868 


280 


11148 


280 


11428 


280 


11708 



1180 


14648 


280 


14928 


280 


15208 


280 


15488 


280+600 — 


16418 


280 


16698 


280 — ■ 


16978 


280 


17258 
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6.4 KL10 Synchronous Cost 

Assumptions: 

1. For comparison, we cost the "natural" combinations 
for the KL, i.e. 12 low speed sync, 4 low-speed 4 
hi-speed. 

2. DN20 needed for first sync line 

3. B is sync requires a separate DN20. 

Case I (12 low-speed lines) 



COST/ 
LINES LINE PWR/PKG OPTION CUM TOTAL 





6595 


2 


3439 


3 


2387 


4 


1861 


5 


2071 


6 


1773 


7 


1560 


8 


1401 


9 


1320 


10 


1217 


11 


1132 


12 


1061 



(DN20 CA + DN20 BA) 
5916 



2233 



679 


6595 


283 


6878 


283 


7161 


283 


7444 


679 


10356 


283 


10639 


283 


10922 


283 


11205 


679 


11884 


283 


12167 


283 


12450 


283 


12733 



Case II (4 low-speed, 4 hi-speed) 

4th (L.S.) (as above in CPU drawer) 7444 

5th (H.S.) 2830 2233 597 10274 
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6 th 


(H.S.) 


1714 


7 th 


(H.S.) 


1341 


8 th 


(H.S.) 


1155 



597 


10871 


597 


11468 


597 


12065 



6. 5 Do 1 ph i n Synchronous Cost 

Assumptions: 

1. Two pairs of cases are considered: 

1. 12 slots of first line unit cage are used. 

2. 12 slots of an added line-unit cage are used. 



2. A "Memory" cabinet already exists for async/unit 
record (analogous to console F.E. on KL) . 

3. In case (1), 18 slots are left over for async or 
more sync-lines (assuming a LP module) . In case 
(2) , 30 slots are available for async/ more sync. 

4. A controller (128K) must be added for sync and will 
control all lines costed. 



LINES 


COST/ 
LINE 


PWR/PKG 


OPTION 


CUM TOTAL 


1 


910 


— ■- 


850+60 


910 


2 


485 





60 


970 


3 


343 




60 


1030 


4 


273 





60 


1090 


5 


230 


■ ■ 


60 


1150 


6 


202 





60 


1210 


7 


181 





60 


1270 


8 


166 





60 


1330 


9 


154 





60. 


1390 
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60 


1450 




60 


1510 




60 


1570 





10 145 — 

11 137 

12 131 

Case (1) B (first L.U. box + 4 LS + 4 HS sync): 

(same as above thru 8 lines — takes 12 slots) 
Case (2) A (add L.U. box for 12 sync lines) : 



COST/ 
LINES LINE PWR/PKG OPTION CUM TOTAL 



1120 210 850+60 1120 

(Box+backpanel) 



2 590 

3 413 

4 325 

5 272 

6 237 

7 211 

8 193 

9 178 

10 166 

11 156 

12 148 



Case (2) B (add L.U. box for 4 LS 4 HS sync) : 

(same as (2) A thru 8 lines — takes 12 slots) 



60 


1180 


60 


1240 


60 


1300 


60 


1360 


60 


1420 


60 


1480 


60 


1540 


60 


1600 


60 


1660 


60 


1720 


60 


1780 



Page 26 

6.6 Unit Record Cost Comparison (Dolphin Vs. KL) 

6.6.1 Printers - 

Assumptions: 

1. On Dolphin, coram cabinet is already in place for 
async lines on minimum system. 

2. On KL, console drawer is already in place. In case 
of printers #3 and #4, Dn20 is already in place and 
only a DNHXX drawer and LP20 must be added. 

3. Cost of printer device not included, but 600 LPM 
band printer is expected to cost about the same as 
300 LPM, LP05 for a 2:1 price-performance 
improvement from KL to Dolphin. 

No. of Printers KL ($) Dolphin ($) 



Cumul . A Cumul . 



1 796 796 600+60 = 660 

2 796 1592 60 = 720 



796 


796 


796 


1592 


233+796 


4621 


796 


5417 



3 2233+796 4621 60 =780 

4 796 5417 60 = 840 



6.6.2 Card Readers - 

1. On Dolphin Unit Record cotroller is already in 
place for first line printer. 

2. On KL, console drawer is already in place. DNHXX 
drawer is not in place. 

No. of Card Readers KL {$) Dolphin ($) 



Cumul. A Cumul. 



1 422 422 60 60 

2 2233+422 3077 60 120 
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7.0 POWER 



The I/O Subsystem portion of the Mercury System has the 

following power requirements: 

Voltages -5.2V +5V +12V -12V 

ICCS 17A llA 

Miniport HA 

Mercury Microcontrollers (4) 44A 

Mercury Memory (4 MMll-L's)* 21A 2.3A 0.1A 



17A 87A 2.3A 0.1A 
*if required 

The Line Card Assembly portion of the Mercury System 
has the following power requirements: 

Voltages +5V +12V -12V 

64 Line Units RS232C 60A 10A 10A 

or ■ 

32 Line Units V. 35 

or 

combinations thereof 

(Unit Record included) 
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8.0 RISKS AND DEPENDENCIES - 

8.1 Risks: 

1. ICCS bus fails or slips. 

2. Staffing of ICCS bus adapter is delayed 

3. Mercury Comm/UR box fails or slips (but Hydra FCS 
is three quarters before Dolphin FCS) . 

4. Synchronous performance is worse than expected 
because of added DECNET functionality (like 
Routing) . 

5. 256KB of memory is not enough. 

6. 64K RAM not available in time for Hydra, causing 
them to use a smaller RAM. 



8.2 Dependencies: 

1. ICCS bus development in Tewksbury (this development 
currently has no manager). 

2. Mercury/Hydra hardware development. Currently 
fully staffed. 

3. Dolphin/ICCS port adapter (done locally in 
Marlboro) . 
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9.0 UNRESOLVED ISSUES 



1. Size of memory resident on controller module (32KB 
- 256KB). Depends on chip selection/availability. 

2. Bandwidth of ICGS bus (range of 3 - 10 Mbyte/sec 
depending on Link logic). 

3. Spec for Dolphin ICCS port commands. 

4. Device packet specs for ICCS bus which are: 

— 36 bit compatible (for disks) 

— common among Dolphin/VAX/11. 

5. Detailed design of Link, ICCS bus. Mercury 
controller, and line cards. 

6. Bus design between Mercury controllers and 
Link/Miniport . 

7. Processor design for scanner/framer. 

8. Power for controller/link. 

9. Modularity of line unit backpanel connections. 

10. Number of line unit slots available in I/O cabinet. 

11. Power integrity monitoring method in I/O cabinet. 

12. Synchronous thruput on Dolphin. 

13. Extent to which Dolphin/Hydra Comm. code can be 
shared. 

14. Effect of expanded DECNET functionality on 
synchronous performance/memory. 

15. Whether TTYSER can be transplanted to the FONZ 
controller . 
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Figure 1. System PMS showing relationship of Mercury Communications 
Subsystem to HYDRA Processors (Pc's) 
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